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(57) Abstract: A system and method fur performing modeling, prediction, optimr/ation. and control, including an enterprise wide 
framework for constructing modeling, optimization, and control solutions. 'Vh& framework includes a plurality of base classes that 
may be used to create primitive software objects. These objects may then be combined to create optimization and/or control solutions. 
'Ilie distrilrated event-driven component architecture allows much greater flexibility and power in creating, deploying, and modifying 
modeling, optimizadon and control solutions. The system also includes various techniques for performing improved modeling, 
optinaization. and control, as well as improved scheduling and control. For example, the system may include a combination of 
batch and continuous processing frameworks, and a unified hybrid modeling framework which allows encapsulation and composition 
of different mode] types, such as first principles models and empirical models. The system may further include a moie flexible 
con6guration of the decision-making hierarchy. The system further includes an integrated process scheduling solution referred to as 
process coordinator, which is an enterprise scheduling /control application that seamlessly incorporates the capabilities of advarKed 
control and execution into a teal time event triggered optimal scheduling soludon. The process coordinator includes a number of 
innovations, including schedules based on real time infomiation, uniBcaiion of scheduling and control tasks, and blending of batch 
and continuous representations. l*he process cooidinator system may thus operate to combine scheduling and contiol into a powerful 
hybrid emnronment. 
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TTIXE: SYSTEM AND METHOD FOR ENTEBPBISE MODEUNG, OPTIMIZATION AND CX>NTROL 



Backgrouod of the Invention 
Field of the Invention 

The present mventioa generally relates to the fields of modeling, optimization, and control More 
paiticularly» the present invention relates to providing an enterprise wide firamewoik for constroctuig modeling, 
optimization, and control solutions. Hie present invention iurther relates to various techniques for performing 
10 improved modeling, optimization, and control, as well as improved scheduling and control. 

Description of the Related Art 

Numerous industries are in the midst of a technological revolution. Throughout today^s businesses, 
information is being made available &om diverse sources at a rapid rate. In addidon, abundant amounts of historical 

15 data from diese sources are accumulating but are not being fully leveraged. Customers expect immediate responses 
and 4^^anfi the highest quality products and services. To remain competitive, businesses must be able to operate 
optimally while fiilfilling the customers' needs. 

The need to operate optimally requires that businesses be much more flexible, have immediatB aocess to 
different forms of information throughout tbe enterprise, and be able to use diis information to solve problems in 

20 real thne. A business must be able to utilize the information effectively and react to the information as it becomes 
available ratiier than waiting for it to appear in periodic reports. The problem is that the information comes from 
different areas of the business, has different meaning to difiterent levels of die business operation, and is utilized in 
different ways. The business must be able to gather information, analyze the information, utilize die infonnation, 
and execute decisions all in an optimal mannftr widi respect to the entire business in order for it to c^^eiate most 

25 profitably. ' 

Tools have been developed to improve separate aspects of business operations. Examples include tools for 
supply chain management and advanced process controL However, these tools applied in isolation do not solve the 
enterprise-wide problems. An enterprise-wide solution is one that views the business as a whole. Although 
businesses have tried to integrate different individual solutions to achieve an enterprise-wide solution, these 

30 attenq>ts have failed. 

Integration of separate solutions into a single business solution is often misrepresented. The benefit of 
integration comes not from loose bridging between disjoint applications but ratiier from designing, from the 
begxaning, tight integration of different applications. For exaniple^ one decision process cannot produce an optimal 
decision widiout knowing both the state of the process that it affects and the ramifications of diat decision on the 

35 dependent processes. 

Any successful solution to the enterprise-wide problem should have an integrated architecture that 
combines many diverse tedmologies into a unified framework. An enterprise-wide solution should have extensive 
information-handling capabilities, a complete set of automatic decision-niaking tools, and a flexibfe azchilectuie 
that addresses the broad scope of problems faced throughout the enteiprise. 
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Figure 1 ilhistratBS die coccept of automated decision roakixig accoxding to die prior art In automated 
decision xnakoag, it is presumed diat a pnxress or system exists upon which decisions are to be made. Part of die 
automated decision making process is to collect data, e.g.» historical data of diat process, and use this information to 
build knowledge or information about how die process behaves. This learning or knowledge may be continually 
S added to or refined as the process is controlled. The information or knowledge that is gathered over time can then 
be used to perform intelligent decision making. For exanqile, the knowledge about how the process behaves can be 
combined with goals and objectives of how die process is desired to behave in order to generate actions that can be 
used to manipulate the behavior of the process or system. Thus, a model of the system or process can be used in 
addition to a solver or optimizer that optimizes the process according to a desired problem formulation or objective 
10 function. 

Figure 2 is a flowchart, diagram generally illustrating the prior art method of creating and using models and 
optimi2»tion procedures to model and/or control a process. As shown, in step 202 the method involves gathering 
historical data which describes the process. This historical data may comprise a combination of inputs and the 
resulting outputs when these iiqyuts are applied to dse respective process. This historical data may be -gathered in 

IS many and various ways. TypicaOyt large amounts of historical data are available for most processes or enterprises.- 
In. step 204 the method may preprocess the historical data. The preprocessing may occur for several 
reasons. For example, preprocessing may be performed to manipulate or remove error conditions or missing data, 
or accommodate data points diat are marked as bad or erroneous. Preprocessing may also be performed to filter out 
noise and unwanted data. Further, preprocessing of the data may be performed because in some *cases the actual 

20 variables in die data are themselves awkward in modeling. For example, where the variables are temperature 1 and 
temperature 2, die physical model may be much more related to the ratio between the tempoatures. Thus, radier 
than apply temperature 1 and tenqieniture 2 to the model, the data may be processed to -create a synthetic variable 
which is die ratio of die two tenq;ierature values, and die model may be used against die ratio. 

In step 206 die model may be ^created and/or trained. This step may involve several steps. First, a 

25 representation of the model may be chosen, e.g., choosing a linear model or rzonlinear model If the model is a 
nonlinear model, the model may be a neural net structure. Further, the neural net structure may be a tuUy 
connected neural net or a pardy connected neural net. After the model has been selected, a training algorithm may 
be applied to die model using die historical data, e.g., to train the neural net. Firudly, the method may verify die 
success of this training to detemune whedier the model actually corresponds to the process being modeled. 

30 In st^ 212 the model is typically analyzed. This may involve applying various tools to the model to 

discover its behavior. 

Finally, in st^ 214, the model may be deployed in the **rcal worid" to model, predict, optimize, or control 
the respective process. The model may be deployed in any of various manners. For example, die model may be 
deployed singly to perform predictions, which involves speciiying various inputs and using die model to predict 
35 the outputs. Alternatively* the model may be employed with a problem formulation, e.g., an objective fimction, and 
a solver or optimizer. 

Figure 3 iUustrates the traditional prior art ^3proadi to scheduling/optimization problems. Figure 3 is a 
graph which illustrates various types of decisions and die prior art methods ^ically used in making these 
decisions. The graph has two axes as shown. The X axis represents the process and decision type. The X axis 
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represents the process type ranging from continuous processes at die origin, to batch' processes, and then to discrete 
processes. In a continuous process, material is continuously flowing through a system, and die automatioa solution 
may be continuously gathering measurements and continuously making decisions. A batch process presumes diat 
die process occurs in batches. The Y axis represents the scope and resolution of the decisions being made. At the 
5 origin, the scope and resolution of the decisions are local involving very simple decisions. As Y increases decisions 
become more complex, until at the highest point of the Y axis die system involves planning die strategy of a whole 
enterprise* 

As shown in Figure 3, prior art solutions applied in this matrix are typicaUy very distinct in nature. For 
example, control solutions in a continuous world and a control solution in a batch world have very little common 

10 software or common representation. Rather, these are typically different products. This limits die ability to create 
more interesting and intelligent solutions to various problems. 

As shown, the prior art approach has typically used an "islands of technology^ approach conqprising 
separate applications^ e.g., a separate scheduler application, a separate recipe execution application, and a separate 
controller application. A solution provider may then attempt to combine ttiese separate applications using a form of 

15 ^glue logic" diat enables some forms of primitive communication. One of the drawbacks widi diis traditional 
approach is that the afypUcations generally can only exchange basic» static information. In addition, diese different 
high-level applications typically have differences in modeling, framework, communication, visualization, and 
execution, and lack adequate intercommunication to provide a tme enterprise- wide solution. 

Thus, the traditional prior art approach to decision making across the enterprise may be referred to as 

20 "system integration". The prior art method presumes different pieces of software that may perform different 
functions, such as continuous control, batch control, optimization, scheduling, etc., and these dififezent pieces are 
"glued together*' to attenq)t to provide an enterprise solution. In addition, as mentioned above, each of these 
different applications cannot take advantage of all of the enteiprise data which would be desirable to optimize the 
entire enterprise. 

25 Therefore, an inqiroved system and method are desired for providix^ a modeling, optimization, and 

. control system. An improved system and method are also desired for providing various improved modeling, 
optimization, and control techniques. 

Summary of the Invention 

30 The present invention comprises various embodiments of a system and method frir performing modeling, 

prediction, optimization, and controL In one embodiment, the present invention includes an enterprise wide 
framework for constructing modeling, optimization, and control sotudons. The framework includes a distributed 
event-driven component architecture which allows much greater flexibility and power in creating, deploying, and 
modifying modeling, optimization and control solutions. 

35 In another embodiment, the present invention includes various tecfaniques for perfoiming mxpmved 

modeling, optimization, and control, as well as improved scheduling and oontroL For example, die system may 
include a combination of batch and continuous processing frameworks, and a unified hybrid modeling framework 
which allows enc^isulaticA and con^osition of different model types, such as first principles modek and e i iipi i l ea l 
models. The system may furdier include a more flexible configuration of the decision-making hierarchy. 
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Another embodimeot of die invention includes an integrated process scheduling solution rdtened to as 
"process coordinator". In one embodiment the process coordinator ts designed as an enterprise scheduling / 
control application that seamlessly incorporates tiie capabilities of advanced control and execution into a real time 
event triggered optimal scheduling solution. The process coordinator of diis embodiment includes a nuniber of 
S innovations, including schedules based on real time information, unification of scheduling and control tasks, and 
blending of batch and continuous representations. Hie process coordinator system may thus operate to combine 
scheduling and control into a poweriul hybrid environment This operates to provide a more enterprise-wide view 
of the complete solution or system, enabling more intelligent scheduling and controL 

10 Brief Descriptjon of the Drawings 

A better understanding of the present invention can be obtained when the following detailed descr^tion of 
fixe preferred embodiment is considered in conjunction with the following drawings, in which: 

Figure 1 illustrates the concept of automated decision making according to the {Hior art; 
Figure 2 is a flowchart diagram generally illustrating the prior art method of creating and using models and 
IS optimization procedures to model and/or control a process; 

Figure 3 ilhistrates the traditional prior art approach to scheduling/optimization problem^ 
Figure 4 illustrates a simplified and exemplary view of one embodiment of a system according to tfie 
present invention; 

Figure 5 illustrates the component architecture according to one embodiment of die invention; 
20 Figure 6 iUustratcs representative examples of various of the component or object classes conq>rised in the 

architectuze of the preferred embodiment; 

Figure 7 ilhistrates an example of an encapsulated decision engine; 

Figure 8 ittustrates the Decision Engine component used as a modular component or object in a hi^er 
level solution; 

25 Figure 9 illustrates die gr^h of Figure 3, but having the approach used according to one embodiment of 

the invention; 

Figure 10 illustrates die interactions of events between enterprises; 
Figure 11 illustrates the unified modeling framewink according to one embodiment; 
Figure 12 illustrates an example of model aggregation according to one embodiment of die invention; 
30 Figure 13 iUustrates two exanoples of tradrtioxuddecision-tiialdzighierarGlu 

Figure 14 iUustiates a flexible decision-making hiecaichy according to one embodiment of die invention; 
Figure 15 illustrates a non-hierarchy decision-making fiamewoxk; 
Figure 16 is a block diagram of a digester line exanq>le; 

Figure 17 illustrates a problem formulation fat an optimization solution which may be created using die 
35 cmnponent architecture of die preferred enibodiment; 

Figure 18 illustrates flexible dynamic optimization i^iidi may be pcifonu ed according to one enibodiment 
of die invention; 

Figure 19 iUustiates embedded data processing widiin an optimization solution; 
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Figure 20 ilhistrates tfie manner in which procedures may be tieated as models in one embodiment of (he 
invention; 

Figuze 21 illustiates the manner in which sohitions may interact to provide an integrated dedsion- 
optimization network; 
5 Figure 22 ilhistrates a basic example of a process being controlled; 

Figure 23 ilhistrates the traditional prior ait approach to scheduling/optimization problems; 

Figure 24 illustrates an enterprise modeling/optimization system according to one embodiment of the 
present invention; 

Figure25 iUustrates a traditional production scheduling exannple acoordiiig ^ 
10 Figure 26 illustrates flexible scheduling according to one embodiment of the invention; 

Figure 27 illustrates the manner in which this embodiment of the invention may operate to control or 
enable flexible transitions; 

Figure 2S ilhistratBS tiie manner in which dynamic modds provide behavior; and 

Figure 29 illustrates the manner in which the system performs event triggered le-^scheduling. 
15 While the invention is suscq)tibie to various modifications and alternative forms, specific embodiments 

thereof are shown by way of exsaapl^ in the drawings and will herein be described in detail. It should be 
understood, however, that the drawings and detailed description thereto are not intended to limit the invention to 
the particular form disclosed, but on the contrary, the intention is to cover aU modifications, equivalents, and 
alternatives felling within the spirit and scope of the present invention as defined by the appended claims. 

20 

Detailed Description of the Embodiments 

Figure 4 - Exemplary System 

Figure 4 illustrates a simplified and exemplary view of one embodiment of a system according to the 

25 present iavention. As shown, the system may inchide one or oaore computer systems 102 ^^ch interact with a 
process, system or enterprise 104 being modeled, optimized and/or controlled. The computer system 102 may 
represent any of various types of conoputer systems or networks of computer systems which execute software 
program(s) acoordiiig to various embodiments of the invention. The software progcam(s) may perform various 
aspects of modeling, prediction, optimization and/or control of the process 104. 

30 As noted above, the process 104 may be any of various types of process, system or catsxpasc tiiat may be 

modeled, predicted, optimized and/or controlled, and element 104 is referred to generally herein as a process for 
convenience. Exan^les of the process 104 include a manufacturing process, a chemical process, financial services, 
a supply chain process, an e-commerce process, such as a business-to-consumer e-conunerce process or a business- 
to business e-commerce process, a bnsiness-to business e-commerce marketplace, etc In the followii^ discussion, 

35 the process 104 is considered to be a manufiicturiiig or automation process. However, ttus is not i ntended to limit 
the invention, it being noted tiiat the systems and methods desoibed herein may be readily used in performing 
modeling, optimization and control of any type of process, system or enterprBe. 

For exampl&t with respect to a business-to business e-commerce marketplace process, die conoputer 
systBm(s) may execute software which optimizes various business transactions held in an electronic forum. 
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Tluis, die system and metiiod may provide an environment for die decision owking process of gathering 
data, accumulating knowledge, and creation of modeb of the process for predictive modeling or control The 
system and method may further provide an environment for making optimal decisions using an optimization solver, 
and carrying out those decisions, e.g., to control die enterprise, which may be apphed to a number of dififerent 
5 applications such as automation, control, financial services, electronic commerce^ etc. 

The one or more computer systems 102 prefoably include a memory medium on which con^nter 
programs according to the present invention may be stored. The term *inemoiy medimn" is intended to tndude 
various types of memory or storage, inchidixig an installation mediimi, e^g^ a CD-ROM, or floppy disks 104; a 
computer system memory or random access memory such as DRAM, SRAM, EDO RAM, Rambus RAM, etc.; or a 
10 non*volatile memory sudi as a magnetic medium, e.g., a hard drive, or optical storage. The menKiry medium may 
comprise other types of memory as well, or combinations diereof. In addition, the memory medium may be located in 
a first computer in which the programs are executed, or may be located in a second different conjurer which connects 
to die first computer over a network, hi die latter instance, the second computer provides the program instructions to 
the first conqputer for execution. 
IS Also, die oonqniter 8ystBm(s) 102 may take various forms, including a peraonal^mputBr system, mainfianie 

conq>utBr system, workstation, network appliance, internet appliance or other device. Ih general, die term ''con^>utBr 
system" be broadly defined to encompass any device having a processor which executes tnstmctions fiom a 
memory medium. 

The memory medium preferably stores one or more software programs for performing various aspects of 

20 modeling, prediction, optimization and/or control of the process 104. The software program(s) are preferably 
inq;>len3ented using conqKment-based t^jmitpie^ and/or object-oriented techniques. For example, the software 
program may be implemented uso^ ActiveX controls, C-H- objects, Java objects, Microsoft Foundation Classes 
(MFC), or other technologies or methodologies, as desired. A CPU or processor executing code and data from the 
memory medium comprises a wie^ng for cieating and executing the soilware program according to -the methods or 

25 flowcharts described below. 

Various embodizoents further include receiving or storing instructions and/or data in^lemented in 
accordance widi the foregoing description upon a carrier medioirt Suitable carrier media inclnde a memory 
medium as described above, as weU as signals such as electrical, electromagnetic, or digital signals, conveyed via a 
communicadon itierfi'inn such.as networks and/or a wireless link. 

30 One embodiment of die present invention provides a new architecture for providing software classes and 

objects or components for perfoiming various aspects of modeling, prediction, optimization and/or control of a 
process, such as process 104. This new architecture utilizes a set of component primitives which comprise reusable 
and configurable components diat can be assembled in different ways to provide various modeling, optimization, 
control and decision solutions. Thus these coioponents can be constnicted or buih in dififerent ways to provide 

35 different higher level sohitions. Ihos, die components can be applied as necessary to provide a modeling and 
opthnization sotutfon as appropriate for the sttuatton or enterprise. Thus, the system does not include predefined 
hig^-level solutions like a scheduler, controller, estimator, etc. Rather, die corrponents are primitives ttiat can be 
used to constmct different types of high-level sohitions such as diese. 
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Figure S - Component Architecture 

Figure 5 iUustrates the component architecture according to one embodiment of &e inveatioit The system 
comprises a flexible, distributed architecture conq>osed of configurable components. The architectuie enables the 
development, deployment, operation, and support of highly inter*operable enterprise optimization solutions. The 
S architectuie of the present invention provides flexibility and modularity in deployment, execution, management, 
and visualization of modeling and optimizatian solutions. 

As shown, the coniponent architectuie may include a plurality of conqxinent architecture classes 122. 
These base classes 122 can be used to create or instantiate various component objects 1-24, which are instances of 
tiie base classes. Further, new classes and/or objects can be created from this set of base classes 122 and 
10 con^onent objects 124. The conponent objects 124 can be combined or used to create higher level objects or 
applications. 

The component architecture may include a plurality of various object management tools and facilities such 
as global n^miyTgi storage and retrieval, cataloging and location, project grouping, deployment, revision tiacldttg 
and visualization management The uniform object management &cilities included in the system provide systematic 
IS management of project complexity. 

Figiire 6 - Exemplary Object Classes 

Figure 6 illustrates representative examples of various of the component or object classes comprised in the 
architecture of the preferred embodiment As shown, the preferred embodiment may include different components 
20 or primitive object classes for modeling, visiudization, simulation, optimization (solver), deployment, ^ecution, 
configuration, management, communication, reporting and archiving, among others. These components comprise a 
set of base classes from which various instances of ttiese classes, or objects, may be generated. These instances 
may interact in an event based manner and may be combined to perform higher-level applicaticms. 

The visualization and configuration corqx>nents include a framework which provides web enabled access, 
25 enterprise wide access, on demand attachment, and view customization. Using the visualization and configuration 
components, the user can perform a variety of functions such as viewing historical data, monitoring debugging 
traces, monitoring decision eqgine executioii, accessing solver diagnostics, locating and managing the decision 
engine, reconfiguriog the deployed decision engine, and monitoring alarms and events. 

For more detail on the base classes conq>rised in die component architecture, please see the document 
30 tided '^Business Requirements Documenf * enclosed herewith. 

Figure 7 - Encapsulated Decision Engine 

As shown in Figure 7, the various objects can be used to encapsulate die Decision and Optimistion 
Solution, i.e., the decision making process, as a "Decision Engine". The Decision Engine may thus be an 
35 encapsulation of die knowledge and the decision mairwig logic into a modular, portable, configurable and extensible 
conqmnent The Decision Eogxne may be an enrapgiiiatt*!! conqKment or object which has its own defined API. 
Ihe Decision Engine noay tbus be a portable conqxment diat can be invoked in a variety of contexts, and can be 
reused in difGeient qjplications. Figure 8 illustrates fbc manner in which die Decision Engine component may be 



7 



wo 01/77872 PCTATSOl/l 1214 

created fiom tiie various pximitive objects, and also illustrates the maimer in whicb tfie Decision Engine component 
may be used as a modular component or object in a higher level solution. . 

The con^onent architecture of the prefened embodiment includes event triggered execution. In 
traditional prior art systems, execution is performed on a fExied periodic basis. As shown» the decision engine 
5 component and other component functionality may be invoked in various contexts and in response to various 
events. Execution of the decision engine may be triggered based on various events such as a syncfaronous^clock, an 
external condition, a procedural step» or automation code, among ofliers. This flexibility allows die creation of 
powerftil custom solutions. 

Hie component architecture of the preferred embodiment also provides flexible deployment, wherein the 
10 modular decision engine component and other solutions created in the architecture of the present invention may be 
deployed in a variety of execution contexts. Exanqsles of where the decision engine conq>onent may be employed 
include a web client/web server environment, a workstation application and an application server. 

Figure 9 ■ Unified Approach 

Figure 9 illustrates the graph of Figure 3, but having the sqiproach used according to one embodiment of 
the invention. As noted in die background section, in this graph the X axis represents the piocess and decision 
type, where die values along the X axis vary from continuous processes at the origin, to batch processes as X 
increases and then finally to discrete processes. The Y axis represents the scope and resolution of the decisions 
being made. At the origin, the scope and resolution of the decisions are local involving very simple decisions, and 
as Y increases, decisiozis become more con^lex until at die highest point of the Y axis die system involves 
planning die strategy of a whole enterprise. 

As shown, the component architecture of the present invention allows different decision making 
components to be applied and spread across diis 2-dimensional space. This leverages the commonality diat is 
found across these two axes, rather dian focusing on die dififerences between them. The present invention thus 
provides the framework for various differem solutions. 

Improved Modeling / Optiiiiization Methods 

Various embodiments of die present invention include techniques for optimizing enterprise operations, 
such as manufacturing operations^ e-commerce operations, business-to-business e-commerce systems, etc. These 
30 techniques are described below widi respect to manu&cturing processes, but may be readily applied to any of 
various enterprise systems, such as diose mentioned above, among odiera. 

Distributed Event-Driven Compohent Architecture 

The underlying architecture of the present system is structured to support the modularity, flexibility, and 
35 scalabili^ needs of niinble enterprises. Conaponents are designed widi plug-^nd-play modularity to allow 
substitution with better technologies, as th^ become available. Business fimctions widun the architectme may be 
replaced widi odxer functions on a con^xment-by-conqKinent basis widi minimal, if any, n^ative inqsact to odier 
business functians. 
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Tiadidonal software developmmt has integrated some of these capabilities into a six^le monolithic 
system; however, re-use of modules becomes impiactical. Even worse, some software products consist of isolated 
islands of functionality with very limited interoperability. In die preferred embodiment of die present invention, 
these functions are components of the architecture but are not dependently integmted. New modules can be easily 
5 added that extend the core functionality widiout replacing die whole enteiprise solution. 

Co0q>onents represent discrete, independent system functions that perfoma a single business function. The 
components are reusable and are combined to fonn modules in support of a specific business process; they can be 
combined, disassembled, recombined, reused, added, and replaced to support change. They standardize die 
fimctionality of each basic business fimction. Through the reuse of the con^sonents, redundancies are removed, and 
10 system processes are assembled in a consistent maimer. A coaq)rehensive series of conq>onents for business and 
specific industries is delivered. Each has a paranoeter configuration layer to facilitate incorporating client-specific 
processing requirements without requiring custom software. 

The system and mediod of the present invention contains general tools leveraged by all components such 
as modeling tools, decision engines, rules-based explanations, and lun-time engines. The present system also has 
. 15 flexibility in dealing with data sources* data transformations, currency conversions, and multi-platform processing. 

Architectural support is provided for the bonding of reusable components. Radier than crafting an entire 
application each time a new process is needed, the present system focilitates die assembly of new business 
processes from existing business con^onents. 

Under diis architecture, processing (preferably all processing) is initiated by an event An event is die 
20 specific occurrence of a process, originating eidier internal or external to die system model. An event can be 
generated through human action or by an automated process. The occurrence of any given event will often become 
die trigger for initiation of other events. The solution to any business problem, then, becomes a series of 
interrelated events. 

Within the system, an event is die result of a specific task such as successfulAmsuccessfid, true/felse or a 
25 numeric task type assignment to select one of a series of options. Events typically have additional tasks to be 
performed based on the result These associated tasks will also produce results and will be classified as events of 
dieir own. This consequence processing is allows entire business processes to be built fiom individual events. 
Any number of events can be created widiin the system to allow for the processiag of any necessaiy scenarios. 

Business enterprises generally interact with odier business enterprises, such as customers^ si^lieis, and 
30 distributors. As shown in Figure 10» these interactions are represented in the present system as events in a manner 
consistent with internal events. Each event, whether internal or external, is tagged with appropriate identity 
infoimation suitable for auditing, genealogical, or other purposes. Thus, events may span enterprises. 

Svnifaesizing Batch and Continuous Processing Frameworks 
35 In one embodiment, the present invention inchides an in^roved system and method for modeling, 

q;)timization and control of batch and continuous processing frameworks. 

Manufacturing processes have traditionally been broken down into two primary modes of operation: batdi 
and continnous. A batch process is one in which a series of operations is conducted over a finite period of time on a 
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discietB, identifiable, and traceable lot of material. A continuous piooess is one in which operations occur 
simultaneously on a stream of mateiiaL 

Batch processes provide Qexibility for producing multiple products in relatively small quantities. In many 
instances batch processes are necessary because they provide die enviromnent required to achieve the physical and 
5 chemical conditions to perform a specific task. For exaixq>le, Tennentation requires a controlled condition for an 
extended period of time. Batch processes make diis possible and are a more flexible solution when compared to 
continuous processes. Although die batch and continuous modes of operation are fundamentally different, the 
overaU objective of each is essentially the same: to convert raw materials into desired products in die most 
economical way. 

10 In addition to fundamental differences between batch and continuous manufacturing, the corresponding 

automation solutions have fundamentally distinct characteristics. Continucms automation solutions are characterized 
by feedback data-flow structures. Batch automation solutions are characterized by event-driven sequences of 
procedural instructions. 

Any actual manufacturing process has elements of t>otfa contiiiuous and batch processing applied at 
IS difierent levels. In managing a continuous process, it is necessary to perform such tasks as startup, shutdown, 
transitions, and grade changes. These tasks have a batch-like nature. Likewise, regulatory and advanced process 
control applied during a batch operation has a continuous nature. In additioii, many processes themselves have bodi 
batch and continuous processing steps. 

Given that a complete automation solution requires bodi continuous and batch mediods, the present system 
20 includes a ficamewodc that seamlessly blends event-driven procedural logic and data-flow structures at all levels of 
die enterprise. 

Hybrid Model Representations 

Optimal decision making requires appropriately constructed models that accurately describe the behavior 
25 of the system. In general, there.are two ways to describe the behavior of a system: 

First-principles Model — A model whose internal mathematical r^resentation is based on an 
understanding of the physical processes that occur widiin die system, lliese knowledge-based models are also 
referred to as fundamental models. 

Empirical Model - A model that cq>tores the iiq>ul/output behavior of the system based on measured data 
30 without relying on knowledge of die physical processes diat occur widun die system. 

There are certain advantages and disadvantages associated with each of these models. 

First-principles models are usuaUy more accurate and can extr^olate better. They also provide a physical 
understanding of the process, which is indispensable for design purposes. Empirical models are applicable as long 
as appropriate data is available. They are, however, limited to the quality and extent of that data. Empirical models 
35 are often fiister and easier to construct and can typically operate at mudi fester pr o ces sing speeds. 

In numerous applications, firat-prindples and empirical models alone are not sufiScient for proper 
description of the problem at hand. To compensate for the lack of information, often-conservative de c i sio ns are 
made to ensure feil-safe operation. Batch processes in particular are known to be prone to this pit^lem (Le. often 
£irst-princq>les knowledge of the process is not completely available, and die available data alone is not rich 



10 



wo 01/77872 PCTAJS0ini214 
enough). la &ct, the development of effective advanced control algoxitbins would be en h anced by the ability to 
leverage the advantages of bofli model xepresentations. 

Empirical modeling has been used to control many sophisticated nonlinear pn)Gesse& One embodiment of 
the present inventbn provides the following capabilities to meet the technological challenge that a systematic 
5 decision-making process presents: 

Composition - Provide encapsulation and composition of different model types. For example, if diere is an 
empirical mod^ for one unit, and a fiist-principles model for anodier unit» enable coheieat in c lusion of fliese 
models into a combined model to allow for unified optimization. 

Training ~ Use of first-principles information (including any expert knowledge) to complement the 
10 available data during training of an empirical model. The resulting en^irical model reconciles the information 
available from process data and expert knowledge into a computationaUy manageable finamewoxk. Thus, real-time 
decision-making in a batch operation scenario becomes munerically feasible. 

Parameter Identification * Use of nonlinear, empirical modeling techniques to identify parameters of fkst- 
princq^les models based on measured data. This faciltty provides parametric identificadon for representations odier 
IS than pure data-fitting forms. 

As shown in Figure 1 1« tlie system and method of this embodiment includes a unified modeling fiameworic which 
unifies the various types of models such as first principle models, also referred to as fundamental models* enq>irical 
models and procedural / recq^e models. In many processes being modeled, die process does not completely conform 
to a single model type. Rather, the process may have elements of several model types. Thus this embodiment of 
20 the present invention allows different model types to be used togedier for to more correcdy represent these types of 
hybrid processes. This provides more flexible modeling services dian have existed in die prior art 

Figure 12 ittustEates an example of model aggregation according to one enibodiment of the invention. As 
shown. Figure 12 illustrates that heterogeneous combinations of model con:q>onents may be aggregated togedier. 
This encapsulated aggregate model, vtiiich may comprise models of different types, may dien be treated itself as a 
25 model. The encapsulated aggregate model is a modular and reusable component which can be used with various 
other objects, as desired. 

Thus, one embodiment of the present invention provides a unified modehx^ framework which allows a 
user to aggregate different model representations for die difficrent pieces of the systenL Thus, the models chosen 
may be a mixture of a neural networic and various other enq;>irical or fimdamental modeliog types. 

30 

Flexible Decision-Making Hierarchy 

In another embodiment, the present invention includes an inqiroved system and metiiod for flexible 
configuiadon of the decision-making hierarchy. 

The traditional operation of an enterprise is ccmposed of a hierarchy of decision-making activities that 
35 include sudi generic tasks as planning, scheduling, optimization, and control The hierarchical sqxaation of these 
tHg|r!» corresponds closely widi immiiTi roles and lesp o nsibihties within the manufjachning organization. Highrlevel 
decision blocks encompass long-term goals of the enterprise and address a broad scope of operations. Low-level 
decision blocks cover shorter rime frames and narrower scope, such as the actual execution of actions on the plant 
floor* 
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Tbe sq>aration of tiiese decision-makiiig elements serves two puxposes. Fiist» it jnovides a divide-and- 
conquer strategy rendenng the decision-makiiig process tractable. Second, it ssolates (asks that have dififeceot 
processing needs and different problem representations. 

Figure 13 illustrates .two exaniples of sudi decision-making hierarchies. The first is typical of batch 
5 process automation; ^e second is typical of advanced process control and optimizatioii for a continuous process. 
Qeariy, die division of tasks is not unique, even wifliin the manufocturing execution layer. FnrtfaBroaore, ^ven that 
die problem characteristics vary considerably widiin a level, it is aiq>arent that no single solution can apply to all 
aperations. 

Rather than force-fittiiig a single sohition to all organizations^ a more powerfbl approach is to provide a 
10 fiamework &at allows die flexible combination of modular decision-making components. This approach allows 
the automation solution to match the requirements of the business more efiEectivdy. This framework also facilitates 
rapid, efficient restructuring of the con^nents as the business needs change. 

A modular decision-making hierarchy can be described by first abstracting the common elements within 
various hierarchies and then blurring, or even eliminatizig, the distinction between traditional layers. This is 
IS illustrated in Figuro 14. 

As shown in Figure 14, each Level of the abstracted decision-makiiig hierarchy exchanges infomation with 
die levels above and below. From die perspective of level B, directives are received from higher level unit A such 
as valve settings, targets, product specifications, or schedules. The characteristics of the information depend on the 
type of decisions to be made at tiiat level. Actions determined at level B are sent to level C. For example, a tank- 
20 level controller receives a target fluid level from an optimizer every ten miirates and relays a sequence of valve 
settings to the control hardware every five seconds in order to maintain the tank at that target level. 

The corresponding upward flow of measurement information fmm CtoB serves several purposes. First, it 
provides feedback about how C has responded to the supplied actions and can be supplied eidier periodically or as 
exception events. Second, level C conveys constraints to level B, such as valve position limits. Third, level C 
25 provides a simplified model of its behavior in order to improve the decision-making process of ^. This third piece 
of information is critical for tightly integrating die decision-making hierarchy while maintaining modularity of the 
individual levels. 

The coordination badcbone link is necessary to integrate tasks that operate under different execution 
mets^shors. For example, if level A operates in a daily transactional environment and level B operates in real time, 
30 die coordination backbone synchronizes dieir execution. Moreover, die backbone will provide n e cessary data- 
translation services. 

Given this abstraction as a basis, various decision-making components can be develoi>ed that will plug- 
and-play widiin an overall framework. An important requirement of this structure is to allow blurring between 
traditionally distinct levels such as scheduling and control. Appropriately-designed infoxxnation exchange between 
35 components moII allow one level to incorporate tibe dynamic behavior of die lower levels widiin its decision-making 
process. U.S. Patent No. 5,933^5 describes a system which demonstrate how die; seamlftss mtegration of steady- 
state optimization and model predictive control — traditionally distinct sub-systems — results in a woxld-dass 
solution. The framework expands the opportunities for developing and integrating such synfliesized solutions. The 
real-world examples in Section 4 illustrate the value provided by sudi int^rated solutions. 
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It is important to rfigKnp^|^|| t-hic architBctuial approach fom two distinct £xtreiaes. 
The first extreme would be to supply a stock planner, scheduler, optimizer, advanced process controller, 
and regulatory controller while leaving integration as an engineering exercise. This has been the traditional industry 
approach and significantly limits the capabilities of the delivered solution based on forced isolation of the decision- 
5 making components. 

The other extreme would be to formulate the entire decision-making problem using a single representation 

and solving it as one unit This would require diat an organization force-fit its operation into a rigid, inflexible; 

sttuctuie ttiat did not accommodate ^namic business strategy. Fuilheiuiore, it is unlikely tibat ttie resulting problem 

formulation would be either solvable or practical to maintain. 
10 Clearly, flexibility in choosing from a spectram of decision-maldi^ strategies provides businesses the 

ability to make more appropriate use of information resulting in inq)roved performance and profitability. 

Previous discussion assumed that the decision-making process, aldtough flexible, is still structured as a 

linear hierarchy; this need not be the case. For example, multiple aspects of the organization might contain 

interdependent yet distinct decision-making processes. Integration of these systems might require further 
IS generalization of the decision-making stmctuxe to enconquiss networks of tnter-commanicating components as 

illustrated in Figure 15. 

More important, diis network will not necessarily remain fixed over the life-time of the organization. Kot 
only will the structure evolve as the goals of the business change, but the structure may also change dynamically in 
response to events internal or external to the organization. This flexible framework allows dynamic reconfiguration 
20 or selection among sets of configurations in response to unexpected events. 

Examples 

This section describes a series of exanq>le5 that illustrate certain aspects of various embodiments of the 
present invention. 

25 

Pulp Mill Batch Digester 
I. Current Approach 

Li the paper making process, wood cbq>s axe broken down into pulp at the pulp milL The customer (paper 
mill) sets die pul^ production requirements in die number of tons per day of pulp, both hardwood and pine. At the 
30 pulp mill, wood chips are mixed with "liquor^ and "cooked" in vessels called batch d^csters. Hie digesters are 
heated widi steam, pressurized, and the chips are "cooked.** When die reaction is conq>lete, the contents are 
released, or "blown,** into a holding tanV and a new batch is started. Only one digester can be released at a time. 
The quality measurement of whether the pu^ is finished cooking is called the Kappa number. Figure 16 is a 
diagram of the process. 

35 At die begimiing of a batch, die operator can speed up the cooking time by addmg more steanL Adding 

more steam will increase production at die cost of product consistency. The availability of steam is a constraint 
.Slowly adding steam gives a more consistent product and better upstream boiler operations. Once die cooking 
temperature is reached, the reaction cannot be slowed down or stopped. To maintain product quality, die digester is 
released, or blown, widiin a finite amount of time when die Kappa number is reached. If the operator has to hold a 
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batdi that is ready to blow, it will continue cooking and thecc will be a vaxiation in ttie Kappa niunber. This 
variation causes problems in the paper machines downstream. The availability of steani» pulp production 
requirements, and product consistency are aU constraints to ttiis process. The Kappa measurement is taken after Hie 
process is coix^)lete or can be estimated with a model while the batch is cooking. This Kappa estimate helps the 
5 operator know when it is time to blow a digester and helps the operator estimate when a batch is done. Over- 
cooking and under-cooking occur with upsets in steam and poor scheduling (e^g. two digesters need to blow at the 
same time). When upsets in steam delivery occur, ttie batch schedule needs to change dynamically to meet tibe 
quality and production requirements. Steam should not be demanded or cut too quicldy, or else an upstream upset 
will occur at the boilers. Hardwood and pine have different cooking tones. These dynamic requirements and 
10 constraints are more dian die pulp mill operator can manage easily. 

Unified Solution 

Combining the ability to predict and control the Kappa number'with a dynamic schedule and the ability to 
control a batch during the cooking phase provides the following: 
15 more consistent product, 

ability to handle steam upsets, 

more stable upstream boiler operations, 

better utilization of capital equipment 

Software that optimizes the batch digester schedule and operations has a tremendous impact on the 
-20 company's profitability. 

Unified Automation System for a Polyolefin Plant 

Although operated continuously, polyolefin plants generally produce difiEerent .grades of resin at different 
times. A polyethylene plant always produces polyethylene; however the resin used for making milk botdes is 
significantly different fiom that used to make garbage bags. The basic specification which distinguishes the grades, 
called Melt Index (MI), is related to the length of the polymer chain, and can be compared to viscosity. The plant is 
operated very differently to produce each grade. The act of changing the line to move between grades is commonly 
called a transitioxL Transitions commonly generate resin, which cannot be sold as either the starting or ending 
grade, and must be disposed of at a loss. The economics of all poly ol^n plants are dependent v^n how transitions 
are maiiaged. On average, diere is one transition a week at each line lasting fiom 4 to over 24 houxs. Lost revenue 
per transition can be S5,000 to over $40,000. Cbnsiderable software, marqiower, and monetary resources are 
employed to effectively manage resources. There is, however, nmch room for improvement 

Current Approach 

35 In die current prior art approach, die first step is to schedule the different products in tone ^ meet the 

customer demands for volume purchased and promised time-of-delivery. In addition to die customer demands, 
stock in inventory and transition costs are considered while determining the schedule. The transition model is a 
fixed matrix of average transition times between eadi possible combination of products. Some combinations are not 
allowed. For example, die transition matrix time for a 4 MI to S MI transition may be 4 hours while a transition 
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from 0.8 MI to 20 NQ may be 12 hours. The actual transition time under cuxrent conditions is not considered. 
Generally the inventory is increased to aifoitrarily high levels so that the schedule becomes a wheel — ^products step 
up from low to high Ml then back down, always moving between adjacent products. This scheme is obviously sub- 
optimal and does not allow for the best ability to promise detivery dates. 

Once the schedule is se^ the transition must be execQted. Two systenos are employed for diis, the 
opcratioss personnel and the control systenn. First ttie transition path must be selected. There are multiple ways to 
efifoct a transition. The line can run at fuU capacity and at fiiU inventories ^^lile rapidly changing the reactant noix to 
ti&e new product This mechanism is usually fast but results in a large volume of transition, or off-grade, material. 
Alternatively, die line can cease production and empty all in-process inventory while on-grade with die current 
product* change the reactant mix while the reactor is empty and not producing, and then re-start the line and build 
the in-process inventoiy. This strategy has litde o£f-grade production, but takes a long time with nothing produced. 
Aldiough these options represent two extremes, there are iiifinite possibilities in between. An optimization engine 
does not decide die best path. The operation staff chooses based on expoience and intuition. 

Finally, die transition is executed based on the operator's goals by the control system. Expert systems and 
advanced control systems are occasionally used to £icilitate die transition- 
Unified Solution 

A combined scheduling, optimal path selection engine, sequential and continuous control automation 
system is desired. The schedide and transition path optimization is preferably solved simultaneously using bodi the 
actual plant models and the currendy relevant economics, including the cost of inventory. Then the transition padi 
may be executed consistently according to phui. A combined sequential and continuous control system with 
contLouous optimization is used for this step. The schedule and path selection can execute in real-time, and tiie 
results can be automatically downloaded to the real-time sequential and continuous optimization engine. Widi such 
a system, inventory levels can be reduced while simultaneously breaking ''product wheei"-type scheduling to 
become more responsive to customer demands. Because die entire system executes rapidly, optional delivery times 
and prices can be quoted based on an accurate calculation of operating costs. Finally, because die entire system is 
fully automated, these quotes could be delivered via e-business v^cles. 

Figure 17 - Problem Formulation for an Optimization Solutian 

Figure 17 illustxates a problem formulation for an optimization solution which may be crea ted usmg the • 
component architecture of the preferred embodiment As shown, an optimization solution may be created including 
a solver, a problem formulation, and a dynamic process model The dynamic process model is an internal model of 
the process which enables prediction of how die process will re^ond over a period of time. Given a particular 
formulation of the problem, various solvers (or c^timizers) may be applied in order to optimize how the process 
will behave over a horizon. This may be used to detennine what control actions should be sent to die process to 
achieve a desired result 

As shown, eaeh of the solver, problem formulation, and dynamic process model may cosiprise different 
modular plug and play conq>onents which may be created using the oonqiQEient architecture described above and 
which may be readily used or inserted to provide different solutions. 
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As showii» the dynamic process model comprises a modular component or object which may be any of 
various types, such as a fust principles or fundam^tal model, a linear model, or a nonlinear model such as a neural 
net model As noted above, the dynanoic process model con^nent may also be comprised of a hybrid model using 
(he uniform modeling framework described above. Thus, die dynamic process model may be a component or 
5 object which represents two or more different model types, e.g., a first principles model and an analytic model 
which are combined togefiier to create a single model object or component 

TliB solver may also be a modular conqxnient or object, and as with the process model object, different 
solver objects or components may be inserted into die solution as desired. As shown, die solver object or 
component may comprise a nonlinear programming solver, a mixed integer nonlinear programming solv^ or an 
10 evolutionary solver, among others. The solver object may also be referred to as an optimization object 

The problem formulation may also be a modular plug and play component or object whidi may be 
inserted into various different solutions. As shown, the pvroblem formulation may take various forms, such as 
predictive regulatory, steady state, and batch trajectory. The problem fonnolation may also have both batch and 
regulatory control formulations. 
15 Thus, tile user may utilize different solver, problem formulation, and dynamic process model objects or 

conqKments in a modular and reconfigurable plug and play manner to create different solutions. This allows a 
much more flexible and powerful mechanism for creating optimization solutions than that existing in tbe prior art. 

Figure 18 - Flexible Dynamic Optimization 

20 Figure 18 illustrates flexible dynamic optimization which may be performed according to one embodiment 

of the invention. The system allows flexible dynamic optimization for different horizons. As is well known, a 
ghriritring horizon refers to the notion in batch processes where the horizon time period in ^ch die results of 
actions may be seen ends at a certain point in time, e.g., when the batch has completed. In contrast, a receding 
horizon may occur in a continuous process and presumes that the results of actions may be reflected over a leogdiy 

25 or even infinite time period As shown in Figure 18 die graph illustrates two examples of a prediction horizon into 
the future. The vertical line contained in the graph illustnites where the process currently is in time. The portion to 
the left of die vertical line ilhistrates what the process has done in the past The lines to the ri^^ of die vertical line 
in Figure 18 represent a possible control action which may be provided to the process and the predictions of how 
die process will react in response to this control actioxL The graphs thus provide a visual metaphor presenting how 

30 the optimization solution is performing over time. 

Prior art systems typically only allowed a predicted fixed set point to be set, herein control actions may 
be provided to attempt to reach fliis fixed set point However, according to one embodiment of the invention, the 
user is able to provide a continuous or discrete line indicating a desired result by configuring constmints and targets 
as trajectories instead of a single set point Thus, the user can indicate that the ten^ierature should follow a certain 

35 trajectory into die future and die user may then be able to <^timize the profile of die tcanpecature on a req»ective 
batch. Huis, as shown, the flexible dynamic optimization allows dynamic predictive control over both a shrinkiag 
horizcHi for batch phase trajectoiy control and a receding horizon for set point regulation. 
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Figure 19 -Embedded Data Prooessmg 

Figace 19 illustrates embedded data processing within an optimizatioa solution. As shown. Figure 19 
illustrates that pre and post processing functions may themselves be encapsulated as respective cooqionents or 
objects. These conqjoncnts may be combined with other objects, e.g., a decision engine which may include one or 

5 more of a solver, problem foimulatioa and process model, to create a more complete solution. Thus, a pre- 
processing object may be created, wherein the pre-processing object may coxnpnse a configunble, modolar and 
phig and play component which may be combined in various manners with die various different decision engines. 
In a similar manner, a post processing function may be encapsulated as an object or component which may also be 
^fwhtpiyt with different combinatians of decision engines. This allows a more modular and configurable 

1 0 m^hanism for developing oomplete modeling, optinuzatton and oontiol solutions. 

Figure 20 - Procedures as Models 

Figure 20 illustrates the manner in which procedures may be treated as models in one enibodinient of the 
invention. As shown, a flowchart or procedure inay itself be treated as a niodel component. This procedural model 
15 component may itself be treated as a "procedural sub-moder, wherein the sub*modeI may be combined with odier 
model types to create a hybrid modular model con^x>nent As shown, procedures may be treated as models in 
various applications such as batch recipe execution, APC management, diagnosis and error recovery* and e^qpert 
system decisions. 

20 Figure 21 - Solutions Interact widiin Framework 

Figure 21 iUustrates ttie manner in which solutions may interact to provide an integrated decision- 
optimization network. As shown, solution A may comprise a model as well as other conq>onents, e.g., a solver, 
constraints etc. which provides actions and objectives to control a second sohition B. The second sohition B may 
itself have a model and other coic4X>nents which may further control another solution or the process or enterprise 

25 being 0K>deled or controlled. As shown, since solution A affects the operation of solution B, it wo\ild be desirable 
for solution A to dynamically understand or have knowledge of how sohition B will respond to the actions provided 
by solution A. Therefore, as shown, in one embodiment of die mvention a model of a solution can also be 
contamed within another sohition. Thus, a model of sohition B may itself be comprised in sohition A, so diat 
solution A may use the model of soludon B in detennining the actions to provide to solution B. As ^own, solution 

30 B may also provide translated results including operating point constraints and the model of solution B to solution 
A for this purpose. This thus provides an integrated decision-optimization network which provides more intelligent 
solutions dian available in the prior ait. 

Separable ModelsAJser Interface Conmonents 
35 Anodier inq>ortant aspect of Ifae architecture of one embodiment is that an application or solution may 

•have a s^nrable mf^^^^ user inteifece which is separate from the decision ermine controlkr or modeL Thus, die 
^^\<^y^}^u mmpf%n#>nt^ g , fhe deofiimi engine is separate from the user interfece component Thus, different user 
inter&ce components can be attached to the deployable conqjonent or sohition in a modular fashion. Thus, the user 
may select among various different interfaces and change various different interfaces in a modular fashion as 
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desired. Therefbie, users can select different types of user interfaces for a single deployable coaq;>oneiit, such as a 
textual description, a graphical description, and use with buttons etc. 



Figure 22 ■ Process Control Example 
5 Figure 22 illustntes a basic example of a process being conHoUed. More specifically, Figare 22 ilhistrates 

a polymer production example wherein a reaction line produces various plastic grades to inventory based on 
scheduled needs. As shown, raw materials are applied to a process. The process may be other continuous or batch 
or may have aspects of both contimious and batch. For example, die process may have a continuous leaction 
process and on-grade control, as well as batch characteristics of lot handling and cozifiguration automation. As 

10 shown, the process may utilize the raw materials to produce various plastic grades su^ as car bumpers (hard), milk 
bottles (medium), and diapers (soft). 

In prior art systews^ production scheduling and production control have traditionally been isolated layers. 
Production scheduling involves meeting demand, meeting delivery dates, and m a naging inventory. Productian 
contiol involves maintaining product quality, maintnining product consistency, operating efiEciently, m a nagi ng 

15 production transitions, and managing unexpected disturbances. Where production scheduling and production 
control are isolated layers, diese layers are unable to properly conmnmicate widi each other to produce an optimal 
entexprise solution. 

Continuing with the example, the process line makes different grades of plastic at different times; The 
plastic component is produced and sent out to inventory and stared in different bins. When the customer makes an 
20 ' order, the business offer causes the triggering of some of this inventory to be shq)ped out to the customer, fa order 
to avoid having the inventory be empty when a customer makes an order, often times die prior art (isolated) 
scheduling component would over fin the inventory in order to ensure that client denoands can be met. Urns, the 
. scheduling component would typically be very conservative about managing the invCTtory. The traditional disjoint 
mediod of solving this problem witiii separate scheduling and control layers* provides an inadequate method of both 
25 scheduling and control, since each conq>onent cannot communicate with each other to provide neccssaiy 
information needed by each for a more intelligent solution. 

Figure 23 - Traditional Approach to Scheduling / Optimization 

Figure 23 illustrates die traditional |nior art approach to scheduling/optimization problems. As shown, and 

30 as noted above the prior art approach has typically used an "^islands of technology^ approach conq>rising separate 
applications, e.g., a separate scheduler application, separate optimizer application, and separate controller 
application. As shown, the scheduler application communicates with the optimizer applicatton which in turn 
commnnicates with the controller application. The controller communicates with the process line to control the 
process being performed. Some of the drawbacks with this traditional approach is that eaxbi of the scheduler, 

35 . opdmizer and controller cannot take advantage of all of die enteiprise data whkh would be desirable to optima 
die entire enterprise. For exanq;»lc, die scheduler could not uttUase inventory data in any type of real time 'fiashion 
and also cannot utilize business system data. Thus, this traditional approach lacked an enterprise*wide view of die 
system. Fuidier, diese sqiarate applications typically do not communicate with each other adequately to form an 
enterprise solution. 

18 
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Figures 24 » 29; Process C rdinator 

Figures 24-29 provide a descnption of an integrated process scheduling solutioD referred to as process 
coordinator. In one embodiment, process coordinator is designed as a manufacturing automation application that 
5 seamlessly incorpocates tiie capabilities of advanced process control and recipe execution into a real time event 
triggered optiiml criiR<i«Kng solution. The process coardinator of this embodiment includes a number of 
innovations, including schedules based on real time information, unificatioa of scheduling and controlled tadcs» and 
blending of batch and contiimous representations. 

The process coordinator system of one embodiment of die invention operates to combine scheduling and 
10 control into a powerful hybrid esviroimient This operates to provide a more enterprise-wide view of the complete 
solution or system, enabling more intelligent scheduling and control since each of diese layers understands the 
operation and needs of the other layer. Therefore, in the example of Figure 22, scheduling would involve 
determining how much of a certain plastic conqx>nent to make and at what time Che plastic component should be 
made in order to meet customer demands, e.g., how many of the hard plastic is produced versus how much of the 
15 sofi plastic is produced. The control task would involve actually controlling the production unit or process to make 
the chosen plastics to the right quality, right consistency and maintaining efficient operations, etc. As noted above, 
• these two operations or decision/automation solutions were traditionally done almost in complete isolation. The 
process coordinator system of this embodiment operates to combine these into an integrated fashion, which allows 
much more intelligent scheduling and controL 

20 

Figure 24 * Enterprise Modeling / Optimgation 

Figure 24 iUustrates an enterprise modeling/optimization system according to one embodiment of the 
present invention. As shown, this system includes a process coordinator which is comprised of or built of a 
plurality of primitive components. The primitive cxin^nents represent building blocks used to create a 
25 modeling/optimization system. As discussed above, this building*block architecture enables the creation of a more 
integrated and enterprise-wide modeling/optimization system. As shown, the process coordinator, according to this 
embodiment, communicates with flie process line inventory data and business system data to provide a more 
completely optimized enterprise-wide system. 

30 Figure 25 - Prior Art Production Scheduling 

Figure 25 iUustrates a traditional jnoduction scheduling example according to tiie prior art Figure 25 
illustrates a production wheel for die above polymer problem. As shown, different grades of material are being 
produced at different times for different lengths of time. The scheduling problem has traditionally pre-assumed that 
the sequence will appear as an ''oscillating wheel of production**, and die only variables are the lengths of each of 

35 die production grades. The lengdis of die production grades comprise how much.product is made of diat grade, 
e.g., how long the grade is made. A sequence list is typically maintained which indicates the grades to be produced. 

As shown, a controller controls die plant in performing die transition '&om one grade to another. The 
behavior of die transition between grades is a function of both the process response and how die process is being 
controlled. However, knowledge of only die process response is tnadegtiate to understand how diat transition is 
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gomg to occur. la gcneia], a model of any control stxategy ttiat is being applied to that process may be needed in 
order to properly understand die transition. Furdiennore» die control strategy may be changing over time based on 
operating conditions. 

In prior art systems, the scheduling problem is traditionally performed with a static fixed cost matrix 
S which defines ttie cost for a transition from any grade to any other. The scheduling problem finds die optimal 
lengdts to meet demands subject to die cost associated widi diese transitions. However, these costs in die static 
fixed cost matrix are typically inaccurate and outdated, since they are typically generated a lengdiy period of time 
prior to their use, e.g^ 3 months ago. 

10 Figure 26 • Flexible Scheduling 

Figure 26 illustrates flexible scheduling according to one embodiment of the invendon. As shown, the 
process coordinator allows flexibility in production order* which may provide irrqiroved response to customer 
requests and more efiecdve management of inventory. 

One embodiment of the present invention operates to perform the scheduling optimization problem using 

IS real-time modeled cost information about how that transition will occor and the associated costs. Thus die system 
uses a model of die physical process, and a model of the control strategy, wherein the modeb include sufficient 
detail in order to be able to predict how die process will behave during transitions. The behavior of die process 
may be a mix of continuous and/or batch type of automation characteristics. Therefore, in one embodimeiit, as 
discussed further below, the system includes a modeling framework that subsumes bodi, i.e., diat handles both 

20 continuous and batch characteristics. Thus, die system includes one modeling fiamewoik for both forms of 
rnodcling. 

Thus, as described above, real cost information is used in performing die scheduling. In addition to this, 
the system and method can optimize the padi itself as well as optimizing die order in wtiich products or grades are 
produced. Thus the system can solve a combined path planning problem and scheduling problem. 

25 In prior art systems, scheduling is performed with no knowledge of how the control is performed. In these 

prior art systems> the system must be very conservative in scheduling because die system can not capture the details 
of how die control system will actually respond. In the system described herein, scheduling and control functions 
are integrated, and the system can be much more aggressive about scheduling. As desCTbed tiirdier below, the 
scheduling solver may include an embedded model of die layer or model below, and the scheduling order may be 

30 updated as necessary based on diis embedded model. 

Thus the system operates to solve the scheduling problem subject to various types of dynamic constraints. 
Iherefore, by integrating scheduling and control functions, the system of the present invention can perform more 
advanced modeling and optimization. 

35 Figure 27 - Flexible Transitions 

Figure 27 illustrates the wiflim^ jn v^ch this embodiment of the invention may operate to control or 
enable flexible transitions. Figure 27 Hhistratcs two graphs of melt index or grade versus time. As shown, widi 
manual oontrol, poor transitioiis im^ occur. As noted above, dus embodiment may operate to combine nonlinear 

20 
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optmuzation and control and dins enable laige rapid consistent transitions necessazy for flexible scheduling. Thus, 
die conlrol used according to diis embodiment provides fast consistent transitions. 

Figure 28 - Dynamic Models Provide Behavior 
5 Figure 28 ilhistrates die manner in which dynamic models provide behavior. Figure 28 also illustrates a 

gr^hof melt index or grade versus time. As shown, unified dynaimcinode]salk>w the process coordinator sysl^ 
to conputB optimal decisions based on accurate costs, constraints and predicted impacts. The system utilizes 
dynamic models of one or more of physical process, control strat^es and business context 

10 Figure 29 - Event Triggered Re-Scheduling 

Figure 29 illustrates the marmer in which the system performs event triggered rescheduling. As shown, the 
process coordinator system may operate to re-schedule gmde production based on requests from priority customers. 
Urns, the process coordinator system may operate to abandon a previous schedule and adopt a new schedule based 
on production requests received from customers. Huts, downstream scheduling may be ro^timized based on this 
15 real time infbrmatioiL Furfhn, die actual iiiQ>act of this custorner request fulfillment is 1^ 

Therefore, the process coordinator system of this embodiment reduces production costs and inventory, 
enables dynamic cummer response, can respond to unexpected events, and can compute accurate pricing and 
deliveiy time. Thus, die system leverages die flexibility of production assets. 

20 Conclusion 

The system of die present invention establishes the architectuml framewodc for a plurality of ^terprise-. 
wide optimization products. This enteiprise-wide solution combines all relevant information across the enterprise 
in order to make optimal decisions. The ardiitectiire is open, extendable, modular, scalable, maintainable, and 
rapidly re-configuiable. 

25 Aldiough the system and method of the present invention has been described in connection with the 

preferred embodiment, it is not intended to be limited to the specific form set forth herein, but on die contrary, it is 
intended to cover such alternatives, modifications, and equivalents, as can be reasonably included within the spirit 
and scope of the invention as defined by die appended claims. 
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1 . A method for enabling a user to create a program for controlling a process, wherein the method 
operates in a system including a computer system which is coupled to the process, the method comprising: 

5 pioviding a plurality of software classes for modiBling, optimization, and deployment; 

providiiig one or more management fodlities for managing die plurality of software classes; 
creating a plurality of software objects based on the plurality of software classes; and 
constmcting an optimization program which uses the plurality of software objectSt wherein said 
oonstmcting is perfomed in response to user input; 
10 wherein the optimization program is useable in controlling the process. 

2. Hie method of claim 1, wherein the plurality of software classes include at least one of a 
modeling class, a simulation class, and an optimization class. 

IS 3. The method of claun 1, wherein' die phuality of software classes include at least two of a 

modeling class, a simulation class, apd an optimization dass. 

4. The method of claim 3, wherein the plurality of software classes fliither include two or more of: 
a visualization class, a deployment class, an execution class, a configuration class, a communication class, a 

20 reporting class, a management class, an archiving class, a pre-processing class, and a post-processing class. 

5. The method of claim 1, herein the plurality of software classes include a modeling class and an 
optimization class; 

wherein said creating the plurality of software objects comprises creatixig a modeling object and an 
25 optimization object; 

wherein said constructing die optimization program comprises constructing die optimization program 
using die naodehng object and the optimization object 

6. Hie method of claim 1, wherein the plurality of software objects are instances of two or more of 
30 die plurality of software classes 

wherein the plurality of software objects conqnise primitives that are useable in creating higher level 
programs. 

7. The method of claim 1, totfaer conqirising: 

35 executing the optimization program, wherein said executing conq>rises executing die plurality of software 

objects. 

8. The mediod of claim 7, wherein said executing the optimization program fiiidier comprises: 
the phuality of software objects communicating with each other using event tnggeied execution. 
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9. Hie me&od of claim 1, 

wherein said creating the optimization program compiises creating a decision engine, wherein tiie decision 
eogme comprises an encapsulation of knowledge and decision tnalring logic; 

wherein the decision engine comprises two or more of a modeling object, a simulation object and an 
S optimization object; 

wherein the decision engine comprises a modular and portable component 

10. The mediod of claim 1 » wherein the one or more management ftcilities comprise one or more of: 
a global naming facility, a storage and retrieval facility, a cataloging and location facility, a project srot^>ing 

10 fodlity, a deployment &cility, a revision tracldng fecility, and a visualization management facility. 

11. The mediod of claim I , wherein the optimization program is operable to perform optimization for 
two or more of: continuous processes, batch processes and discrete processes. 

■ 15 12. The method of claim 1, wherein the optimization program is operable to perform control 

fonctionsfortwoormoreof: continuous processes, batch processes and discrete processes. 

13. TTie method of claim I, 

wherein said creating a plurality of software objects includes creating a model software object that 
20 combines a first-principles model and an empirical model. 

14. Tbe method of claim 1, 

wherein said creating a plurality of software objects includes creating a model soltware object (hat 
combines two or more of: a first-principles model, an empirical model, and a procedural model 

25 

1 5. Tbe method of claim 1 , wherein said creating a plurality of software objects conq>rises: 
creating a dynamic process model object; 

creating a solver object; 

wherein tfie optimization program is constnicted indudinig (be dynamic process model object and the 
30 solver object wherein the dynamic process model object and die solver object operate together to optimize die 
process. 

1 6. Ibe method of claim 1 S, v^crein said creating a plurality of software objects further oooaprises: 
creating a problem formulation object that describes a problem; 

35 wherein die optimization program is constnicted including die problem formulation object; 

wherein die solver object uses information from the problem formulation otject in optimizing the process. 

17. The method of daim 15, 
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^i^bexem the dynamic process model object coin]»rises one of a &st principles model, a linear model, a 

non-linear model, or a hybrid model; 

v^etein the solver object comprises one of a nonlinear programming solver, a mixed integer nonlinear 

programming solver, or an evolutionary solver. 

18. The method of claim 15, wherein said creating a phnality of software objects further comprises: 
creating a pie-processipg object; 

herein the optimization ptogtam is constructed including the pre-processing object 
herein the pre-processing object is operable to pre-process data prior to provision of the data to the 
dynamic process model object or the solver object 

19. The method of claim 15, wherein said creating a plurality of software objects further comprises: 
creating a post-processing object 

w^torein the optimization program is constructed including the post-processing object; 
wherein the post-processing otsject is operable to post-process data received from one or more of 
dynamic process model object or the solver object 

20. The mediod of claim 15, 

wherein the dynamic process model object and the solver object conoqprise a first solution that controls a 
first process; 

the me&od further corrq>rising: 

creating a model of die first solution; 

creating a second solution, wherein the second solution conqmses a second dynamic jn-ocess 
model object, a second solver object, and die model of the first solution, wherein the second solution which 
operates to control a second process, wherein the second solution affects the first solution; 

wherein ttie second solution uses the model of the first solution to dynamically determine how the first 
solution will respond to actions provided by die second solution. 

21. ' The me^od of claim 20, further comprising: 

die second solution using the model of die first solution to dynamically determine how the first solution 
will respond to actions provided by the second solution; and 

die second solution controlling the first solution based on a determination of how the first solution will 
respond to actions provided by die second sohitioit 

22. The metfiod of claim IS, further conoprishig: 

creating a user interface con^nent for die optimization program; and 
associating die user interface component widi the optimization prograza 
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23. The method of claim 1, wherein die process comprises one of: an enterprise, a manufectunpg 
operation, or an e-commeice system. 



24. A control system for controlling a process, wherein the control system con^rises: 

5 a computer system including a processor and a memory mexilimi, wherein the computer system is operable 

to couple to the process; 

a plurality of software classes for modeling, optimization, and deployment; 

one or more management facilities for managjng tiie plurality of software classes; 

a plurality of software objects created in response to the plurality of software classes, wherein the plurality 
10 of software objects inherit functionality ftom one or more of the plurality of software classes; and 
a control program created using the plurality of software objects; 
wherein the control program is useable in controlling the process. 

25. The control system.of claim 24, wherem the plurality of software classes include at least two of a 
IS modeling class, a simulation class, and an opthniTation class. 

26. Thecontrolsystemofclaim24, wherein the phnaUty of software classes furt^ 

more of: a visualization class, a deployment class, an execution class, a configuration class, a communication class, 
a reporting class, a management class, an arohiving class, a pre-processing class, and a post-processing class. 

20 

27. The control system of claim 24, wherein die plurality of software classes inchide a modding dass 
niiii an optimization class; 

wherein the plurality of software objects canxpnse a modeling object and an optimization object; 
vtiierein the control program comprises the modeling object and the optimization object 

25 

28. The control system of claim 24, wherein, during execution of the control program, the plurality of 
softwaie objects communicate with each other using event triggered execution. 

29. The control system of claim 24, 

30 ^utoein die control program caaqxrises a decision engine, wherein die decision engine con^nises an 

encapsu lation of knowledge and decisicm making logic; 

wherein the decision engine comprises two or more of a modeling object, a simulation object and an 
optimization object; 

wherein the decision engine conqmses a modular and portable component. 

35 

30. The control system of claim 24, wherein die control program is operable to perform control 
functions for two or more of: continuous processes, batch processes and discrete processes. 



25 



wo 01/77872 PCTAJSOl/1 J214 

3 1 . The control system of claim 24, wberem the plurality of software objects comprises: 
a dynamic process model object; and 

a solver objcc^, 

wherein the optimization program coxxqirises (he dynamic process model object and the solver object, 
5 wherein the dynamic process model object and die solver object operate together to optimize the process. 

32. The control system of claim 31. wherein die plurality of software ol^jects further comprises a 
problem formulation object diat describes a problem; 

wherein the (^timization program comprises the problem formulation object; 
1 0 wherein the' solver object uses information from the problem formulation object in optimizing the process. 

33.. The control system of claim 31, 

wherein the dynamic process model object comprises one of a first principles model, a linear model, a 
non-linear model, or a hybrid model; 
IS wherein the solver object cons^irises one of a nonlinear programming solver, a mixed iiiteger nonlinear 

progFamming solver, or an evoiuticmary solver. 

34. T1iecontrolsystemdfcIaim31, wherein the pluraUty of software objects further comprises 
processing object 

20 wherein the optimization program con^rises the pre-processing object; 

wherein the pre-processing object is operable to pre-process data prior to provision of tiie data to the 
dynamic process model object or &e solver object 

35. The control system of claim 31, wherein die plurality of software objects furdier -comprises a 
25 post-processing object; 

wherein the c^timization program comprises die post-processing object; 

wherein die post-processing object is operable to post-process data received from one or more of die 
dynamic process model object or die solver object • 



30 36. The control system of claim 31, 

wherein the dysaxaic process model object and the solver object campnsc a first solution that controls a 
fust process; 

wherein the control system further comprises: 
a model of the first solution; 

35 a second solution, wherein die second solution conqncises a -second dynamic process model 

otvjecl; a second solver object; and the model of die^first solution, wherein die second solution operates to control a 
second process, wherein the second sohition affects die first solution; and 

wherein the second solution uses die model of the first solution to dynamically derermine how the first 
solution will respond to actions provided by the second solution. 
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37. The control system of claim 36» 

wherein the second solution is operable to ixse the model of ttxe first solution to dynamically determine 
how the Hist solution will respond to actions provided by the second solution; and 

wherein the second solutioii controls the first sohition based on a determination of how the first sohitton 
will respond to actions provided by the second solution. 

3S. The control system ofdaim 31, fntther comprising: 
a user interface component for the coatrol program; 

vi^ierein die user inter&ce conoponerit is operable to be associated with the control program. 

39. The control system of claim 24, wherein the process comprises ohe of: an enterprise, a 
manufacturing operation, or an &<orranerce system. 

40. The control system of claim 24, wberein die control system comprises a plurality of coniiputer 
systems interconnected via a networlc. 

41. A memory medium comprising program instructions for enabling a user to create a program lor 
optimizing a process^ wherein the memory medium is comprised in a computer system which is coupled to the 
process^ wherein the memoiy mediiun stores: 

a plurality of software classes for modeling, optimization, and deployment; 

one or more management fecilities for Trranagifig die plurality of software classes; and 

^idierein a plurality of software objects are operable to be created based on die plurality of software 

classes; 

wherein an optimization program is operable to be constrocted which uses the plurality of software 

objects. 

42. The meooory medium of claim 41, wherein die memory mediumlhrther stores: 

a plnratity of software objects diat are created based on the pluraUty of software classes; and 
an optimization program that is constructed using tiie plurality of software objects. 

43. A method for enabling a user to create a program for controlling a process, wherein the method 
operates in a system including a computer system which is coupled to the process, the mediod comprising: 

providing a plurality of software classes for modeling, optimization, and deployment; 
providing one or more management facilities for mnnft^m^ the phuality of software classes; and 
creating a plurality of software objects based on &e plurality of software classes, ^lieiein satd creating a 
phuality of software objects cooiprises: 

creatir^ a (fynamic process model object; and 

creadog a solver object; and 
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coastmcting an optixDization program which uses flie plurality of software objects, wherein said 
constructing is performed in response to user input, wherein the optimization program is constructed including the 
dynamic process model object and the solver object, wherein the dynamic process model object and the solver 
object operate together to optimize the process. 

44. The mediod of claim 43, wherein said creating a plurality of software objects finther cocnprises: 
creating a problem fonnulation object that describes a problem; 

'v^ierein the optimization program is constructed including the problem formulation object; 

wherein the solver object uses information from the problem formulation object in optimizing the process. 

45. The method of claim 43» 

wherein the dynamic process model object comprises one of a first principles model, a linear model, a 
non-linear model, or a hybrid model; 

wherem the solver object comprises one of a nonlinear programming solver, a mixed integer nonlinear 
solver, or an evolntionaiy solver. 

46. The mediod of claim 43, wherein said creating a plurality of software objects further comprises; 
creating a pre-processing object; 

wherein the optimization program is constructed includuig the pre-processing object; 
wherein die pce-piooessing object is operable to pre-process data prior to provision of the data to the 
^namic process model object or the solver object 

47. The mediod of claim 43, wherein said creating a plurality of software objects further con^rises: 
creating a post-processing object, 

herein the optimization program is constructed including the post-processing object; 
^(dieiein the post-processing object is opecable to post-process data received firom one or more of tiie 
dynamic process model object or the solver object. 

48. The method of daim 43, 

wherein the dynamic process model object and the solver object compxise a first solution that controls a 
fiistprocess; 

the method further comprising: 

creating a second solution, wherein die second solution comprises a second dynamic process 
model object and a second solver object which qpecate together to control a second process, vdieiem the first 
solution affects tiie second solution; 

creating a model of die second solution; 

including the model of the second solution into the first solution; 
wherein the first solution uses die model of die second solution to determine how die second solution will 
respond to actions provided by die first solution. 
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49. Hie method of claim 43, fuitheroompzisiog: 

the first sohition using the model of the second solution to dynamically deteimine how tfie second solution 
will respond to actions provided by the first solution; and 

the first sohition controlling tiie second sohition based on a determination of how tihe second solution will 
respond to actions provided by the first sohition. 

50. The method of claim 43. fiutfaer comprising: 
creating a user interface component for die optimization program; and 
associating die user intraiaoe component with the optimization program. 

51. The method of claim 43. wherein the process comprises one of: 
operation, or an e-commerce system. 

52. A method for modeling a process, wherein the method operates in a system including a coBapmSBT 
system, the me&od comprising: 

. creating a software program that implements a model, wherein the model combines aspects of a first- 
principles model and an empirical model; 

executing the software program to model the process. 

53. The method of claun 52. wherein said executing comprises executing aspects of die first- 
principles model and die empirical modeL 

54. The method of claim 52, further comprising: 

training the model, wherein said training uses empirical data and first-principles information. 

55. The mediod of daim 52, furdier conqnising: 

identifying parameteis of die first-principles model'based on empirical data, wherein said identifying uses 
nonlinear enqriiical modeling t^hniques. 

56. The method of claim 52, 

wherein the model combines aspects of a first-principles model, an empirical model, and a procedural 

modeL 

57. A method for optimizing a process, the method con^risii^: 

receiving user iiiput which configures constraints and targets of the process as a trajectory; 
controUing die process based on die configured constraints and targets of tin proces?. wherein the process 
is controlled to substantially conform to die trajectory. 



an enterprise, a manufacturing ' 
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58. The method of claim 57, 

wherein said controlling Ae process coiiq>rises optmuziDg the process according to the configured 
constraints and targets of the process, wherein &e process is optimized according to the trajectory. 

5 59. A mediod for enabling a user to create a program for controlling a process, wherein the method 

operates in a system induding a computer system which is coupled to die process, die method comprising: 

creating a first sohition comprising a first dynamic process model and a "first solver, wherein die first 
solution controls a first process; 

creating a model of the first solution; 
10 creating a second solution, wherein the second solution comprises a second dynamic process model, a 

second solver, and die model of the first soludcm, wherein the second solution controls a second process, wherein 
the second solution affects the first solution; 

wherein the second sohition uses the model of the first sohition to deteimine how the first solution will 
iespond to actions provided by the second solution. 

15 

60. Tbe mediod of claim 59, furdier comprising: 

the second solution using the model of the first solution to dynamically deteimine how the first solution 
will respond to actions provided by the second solution; and 

the second solution controlling the first solution based on a determination of how the first sohition will 
20 respond to actions provided by the second solution. 

61. A method for enabling a user to create a program for controlling a process^ ^lerein the method 
operates in a system including a conqniter system which is coiq>led to the process^ the method comprising: 

creating a first solution conqprising a first dynamic process model and a tiist solver, wherein the first 
25 solution controls a first process; 

creating a second solution^ wherein the second solution comprises a second dynamic process model and a 
second solver, wherein the second solution controls a second process, wherein die first solution affects the second 
solution; 

creating a model of the second solution; 
30 including the model of the second solution into the first solution; 

wherein the first solution uses the model of the second solution to dynamically deteimine how the second 
solution will respond to actions provided by die first sohxtioiL 

62. Hie method of claim 61, findierconqmsing: 

35 die first solution using the model of the second solution to dynamically determine how the second solution 

willre^nd to actions provided by the first solution; and 

die first solution controlltng die second sohition based on a determination of how die second solution will 
respond to actions provided by the first sotntion. 
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